home *** CD-ROM | disk | FTP | other *** search
/ Hacker's Arsenal - The Cutting Edge of Hacking / Hacker's Arsenal - The Cutting Edge of Hacking.iso / texts / misc / inputval.txt < prev    next >
Encoding:
Text File  |  2001-07-11  |  6.1 KB  |  126 lines
  1. Input Validation Attacks
  2. ========================
  3. Written by R a v e N for BSRF (http://blacksun.box.sk)
  4. 17/7/2000
  5.  
  6. "Input Validation Attacks". Some of you may be startled by this term. But, to
  7. tell you the truth, it's quite simple, and fun too. Here, let me explain.
  8.  
  9. What's an IVA?
  10. --------------
  11. IVA stands for an Input Validation Attack. I'll try to make this as simple as
  12. possible, so even the ones of you who don't have any programming experience
  13. would still understand.
  14. Suppose you have a program that receives input. That could be practically
  15. anything. In fact, almost every application that you know receives some sort
  16. of input. When you tell your browser where to go, you're giving it input. When
  17. you play a computer game and you tell your figure to move to the left, that's
  18. input. When you type in your password, that's input too. So, what happens when
  19. a program doesn't validate the input that you give it correctly?
  20. Suppose, for example, that if you typed your input, and then a certain
  21. character and afterwards a command and it will be executed? Or maybe, if you
  22. type a password that's too long, the program will go amok and let you in
  23. without the password. Or maybe it'll let you in if you won't type anything
  24. at all.
  25. The program didn't validate the input correctly - it didn't make sure that the
  26. user is typing what he is supposed to type. So let's make a long story short -
  27. there is a bug or a hole in the program or it's implementation that involves
  28. certain input, and the program doesn't make sure that such input is not given,
  29. thus allowing us to exploit the hole. Now for a few examples, to clear things
  30. up and to show you how this can be done and exploited.
  31.  
  32. Examples
  33. --------
  34. The best possible real example that I can think of is the PHF hole. Yes, PHF!
  35. Some of you may already recognize this hole. Yeah, yeah, we know it's dated
  36. back in 1996, but let's forget about it for a second and concentrate on how
  37. this works.
  38.  
  39. Let's imagine we're back in 1996. PHF is a CGI script that comes standard with
  40. the Apache Web Server - the world's most popular web server (and it still is
  41. until this very day). Everything is doing just fine, until Jennifer Myers
  42. found out that the PHF script will accept the newline character and issue
  43. commands to the command line with the webserver's privileges. This means that
  44. if httpd (the HTTP Daemon, i.e. the program that listens on port 80 (by
  45. default) and waits for HTTP connections. The term daemon isn't limited to
  46. Internet-related issues, and is better explained in other BSRF tutorials) is
  47. running as root (which is a very stupid thing to do. Web servers should run
  48. from a very restricted account), every command can be executed with root
  49. privileges.
  50.  
  51. Basically, to get the password file, all you had to do is to type this:
  52. http://www.some-vulnerable-webserver.com/cgi-bin/phf?Qalias=x&0a/bin/cat&20/etc/passwd
  53.  
  54. Then you will get the password file, as if you had console access to a root
  55. terminal and typed in cat /etc/passwd (if the file is shadowed, you can also
  56. get /etc/shadow. After all, you have root permissions). From this point, all
  57. you have to do is to run a password cracker and wait.
  58. Smarter crackers would issue different commands. For example, they could
  59. create an .rhosts file on root's home directory and add their hostname and
  60. username, and then use rlogin to remotely login to that system (if such a
  61. service is running and is not firewalled. But then again, an admin that is
  62. stupid enough to run httpd as root would probably also have it running
  63. unrestrictedly as well). Refer to rlogin's manual page for further
  64. instructions.
  65.  
  66. Analyzing the attack
  67. --------------------
  68. http://www.some-vulnerable-webserver.com/cgi-bin/phf?Qalias=x&0a/bin/cat&20/etc/passwd
  69.  
  70. Hmm...
  71. That's awfully long, isn't it? Let's take it piece by piece.
  72.  
  73. http://www.some-vulnerable-webserver.com
  74. There's not much to explain here - this part tells your web browser who to
  75. contact.
  76.  
  77. /cgi-bin/phf
  78. This part tells your browser to request for the file called phf, under the
  79. cgi-bin directory, which is under the root directory (it's the main directory,
  80. similar to c:\ in the DOS / Windows world).
  81.  
  82. ?
  83. Passes input to phf, the cgi script.
  84.  
  85. Qalias=x
  86. So far this is normal input, which the program (and the programmer) is
  87. expecting.
  88.  
  89. &0a
  90. This is the fun part. &0a is the new line metacharacter. It tells PHF to
  91. start a completely new command line.
  92.  
  93. /bin/cat&20/etc/passwd
  94. The command to execute. Tells PHF to run the following command:
  95. /bin/cat /etc/passwd
  96. The cat program is a standard Unix program that dumps the contents of a file
  97. to the "standard output" (stdout). This usually means your computer monitor,
  98. unless the output is redirected (to the printer, to a file, or in this case,
  99. through a TCP/IP socket and straight down to our browser).
  100. &20 is another metacharacter, which stands for a blank space, which is also
  101. called a "white space" (it is used instead of real spaces because httpd cannot
  102. accept spaces in URL requests).
  103.  
  104. How to prevent such attacks
  105. ---------------------------
  106. First of all, make sure that everything runs with privileges that are as
  107. restricted as possible, and can only access files that it should and has to
  108. have access to (and if so, minimize access. For example: a web server needs to
  109. be able to read html, gif, jpg, cgi scripts or other files that belong to the
  110. web site, but does not require writing access to them). That way you can
  111. minimize or completely eliminate any possible damage.
  112. Also, as a developer, you must take security into mind when you code your
  113. programs, and also test them under unexpectable conditions. In other words,
  114. when you test a car, you test it for all sorts of strange situations and wild
  115. crashes, and drive it through different kinds of terrains. You can't just make
  116. sure that it can drive and then send it out to the market, otherwise people
  117. will realize that although the car works just fine in normal conditions, it
  118. doesn't handle unexpected ones properly, and will eventually switch to another
  119. manufacturer.
  120.  
  121.  
  122. Thank you for reading. You can catch up with other BSRF tutorials at
  123. blacksun.box.sk - just find the tutorials page. And remember, if you have a
  124. question, we have an excellent message board, and you can post your question
  125. there.
  126.